エクストリームプログラミング読書会 第五回

第5回

参加者：@kkd, @ueda, @kobatomo, @got4416

進捗：5章 機会〜責任の引き受け まで(4ページ)

近況

AWS Cloud9でリモートペアプロできる？(@ueda)

そういえばAVAでJavaScriptのTDDも試しました。(@ueda)

先週誕生日だった！ 38才！！(@kobatomo)

テスト駆動開発の本を読みはじめた。写経やっている(got4416)

@t-wadaさんとあったよ(@kkd)

5章

機会

@kkd

「問題を機会に意識的に変換する」は重要だなぁ問題をポジティブに考えられる。

サバイバルモード

@ueda

特になし。

障害があるとどうしてもネガティブになってしまう。

@kobatomo

サバイバルの姿勢とは、「学習するのに十分な時間がない」火消しの状態のことですかね？ 問題を潰していくことやねー

サバイバル＝いきあたりばったり、後先考えず、「その場しのぎ」がよさそう、モグラたたき

リリース前に問題が見つかったとき、落胆する反面。すぐに頭を切り替えている。ソフトウェアを修正できるチャンスを得たと変換しているなぁ。 「リリース前にみつかってよかったね！」

@got4416

「サバイバル」を行っても根本を変えないと、また似たようなことが起こることが多い経験が・・・。 根本原因に対応していない

ただ、根本の問題に手を出したいけど、時間と労力を考えて腰が引けてしまうことも。 みなどうしてる？ 表沙汰にして、ひとまず休憩する。ジタバタしない。開発サイドからすると致命的に思える場合でも、見る人（顧客、利用者）からするとそれほど重要ではないということもある(@ueda)

一人で抱え込まない、チームの誰かに話してみる(@kobatomo)

コストがかかる場合がある。ベビーステップで段階を刻む。応急処置と恒久的な対策を段階を分けて進める(@kkd)

最近は、同じようにできてる。チームで考えてみる(@got4416)

価値の一つの「勇気」との関連が強いように感じる。

バグを隠しちゃうという文化があるなー(@kobatomo)

冗長性

@kkd

地味に大事。大事なことはバックアップシステムで解決！

効率化だけを求めると「冗長」はムダとして認識される可能性がある。必要な冗長性の見極め大事。 朝会、夕会があった。チームメンバからは、同じと言われた。目的は違うけど。

@ueda

課題を解決するのに2つの方法（できれば3つ）を用意することを意識していた時期があります。最近は、とりあえず作ってみて、見てもらって、という感じであまり冗長性を意識していないかも。（次の「失敗」と重なる その課題とは？→10年位まえにデジタルパンフレットの仕事で出来合いのシステム使うか、スクラッチで作るか、ごまかす（？）か、という開発依頼があった時に、別の選択肢も考えておいた。松竹梅揃える(@ueda)

@kobatomo

冗長性の視点は、欠陥の排除にフォーカスしているのであれば納得できる。

レビュー、設計の相談、クラス間の疎結合、TDD、結合テスト、総合テスト、複数人または、視点を変えて欠陥から除去しているなぁ。誰か相手にお願いする場合は、的を絞ってできるだけ短くの配慮もしている。 ベイビーステップでやってます。

@got4416

シンプリシティを頭に置いて冗長性を考えるって難しい。

「冗長であることが実証された場合だけ」冗長な何かを排除できると書いてあるけれども、簡単な話じゃないように思える。

そこまで明確に排除できる何かって「ムダ」のこと？

成功失敗問わず、自分であっても他人であっても経験って大事。 ムダかどうかを見極めるのは経験に左右される？(@got4416)

欠陥以外に冗長性で対応した方がいいものってなんだろう？ 会議をスムーズに終わらせたいので、根回し、打合せ予定を送ったりしてるなぁ(@kobatomo)

データの登録をメールで通知、履歴をダウンロードなどできるようにしておく(@ueda)

目的を合わせるようにコミュニケーションしている

貼っておく。週一回確認する。

改善したことを忘れないように張り出しておく(@kkd)

発言したことを理解しているか相手に確認することも一種の冗長性(@kkd)

失敗

@kkd

タイムボックスで考えるのはいいやり方。

「失敗」と言わずに、「学びの機会」と言うと、気が楽？

@ueda

失敗を恐れて、そのまま突き進んでしまうことがあります。というか、無意識のうちにそうしてしまっているかもしれない。うまく行かなかったことをオープンにして、議論することで次に活かせる。好ましくない実装でも、失敗と認めずそのまま終わらせてしまう（完了する）と、同じ方法を繰り返してしまう。 他の原則とつながってるなぁ(@kkd)

@kobatomo

時間を区切ってやるというのは、篠原さんと一緒に仕事していた時に、やっていたなぁ。設計検討の場も大事ですよねー。 いいね！！(@kkd)

今やってない。一人だから(@kobatomo)

問題が見つかった場合は、これやっているかも？方向性を決めて、再現確認（インプット、関係者と相談）。時間がかかるが少しずつ絞り込んでいく。 小さなインセプションデッキを作ってるような感じ(@kobatomo)

@got4416

学ぶことより、行ったほうが知ることにつながる。

すごく自分勝手な考えだけど、自分の失敗は「経験になる」と許容するけど、他人の失敗を許容できないときがある。余裕さえあれば許容できるかもしれないけれど、余裕がないときにどうすれば良いのか？（他人へのリスペクトが足りない？） 他人の失敗(仕事、子供)を許すにはどうすればよいか？(@got4416) パス(@kobatomo)

追い込んでもいい方向には行かないと思う。時間を作る（残業ではない）(@ueda)

別の機会に話してみる。1on1(@kobatomo)

相手になぜと聞くと尋問しているようになるよ。なぜの使い方は、難しい。(@kkd)

怒っている自分に気づく。なぜ怒っているのか考える。(@kkd)

品質

@kkd

@ueda

今の時間でできる限りのことをする。あとからきれいな方法で完成させる。

いわゆるリファクタリングが、なんとなく頭にあっても手が動かない（動かせていない）ことが多いです。ゆとりを持って、タイミング（サイクル）を決めて実践したいところ。 短期的に間に合わせて機能追加していっても、長期的に要望に答えられなくなるとまずい。(@ueda)

@kobatomo

品質が心配なとき。テストを書いていないコードを改造する時かなぁ。まずは、メソッド単位。クラス単位。アプリ単位。とか少しずつ少しずつですね。担当するところを少しずつ。ベイビーステップ。 自分の品質はバグ数(@kobatomo)

顧客と開発者は品質という信頼関係で結ばれている(@kobatomo)

@got4416

「第1版」に品質の測定に関して何かが書いてあったんだろう？

3段目に書いてあるマネージャの話（品質に対する欲求を仕事以外で満たしていた）って悪い例？ 日本で言うと盆栽？(@got4416) サザエさんの波平がそういう設定(@ueda) カツオが盆栽を壊して怒られてサザエさん一家は平和(@kkd)

品質という言葉の捉え方が色々あると思う(@got4416)

マネジメントの品質(@got4416)

レビュー数、レビューやってるよね、というところのメトリックスを取っている(@got4416)

こういう計測はそもそも必要なのか？という問いかけが必要なのかも(@kkd)

マネジメント品質の今後に期待してます(@kkd)

ベイビーステップ

@kkd

大事だなぁ。開発も改善も個人の変化も。

２つの意味が含まれている、1.小さい歩幅で、2.小さな成功体験を積み重ねること。

@ueda

課題を分けて登録したつもりが、まだまだ粒度が大きすぎるなど ひとつひとつが漠然としている。(@ueda)

直近で必要なことをばらしましょう(@kkd)

あるいは、課題を進める中で適度な大きさに細分化するなど

@kobatomo

ベイビーステップ。大好きです。 アニメじゃない(@kobatomo)

@got4416

立ち止まるのではなく、小さく進む。

人の成長によって歩幅は変わる？変わるのは歩幅でなく速度？（「小さなステップを高速に繰り返し、まるで躍動しているかのように・・・） 前の技と後の技が繋がって、綺麗に流れているように見える(@got4416)

確実に1個1個。気づいたら流れるように見える(@got4416)

物によってはFeedbackにつながる(@kkd)

どの幅で進めばいいか最初はわからない やってみてふりかえってみよう

タスクの粒度は30分から１時間ということもあった(@kkd)

責任の引き受け

@kkd

「タスクを割り当てる」でなく「タスクをとる」という言い方をする

責任と権限でセットだよ、というのは重要

個々の責任について触れているが、チームとしての責任には触れていない。XPってどうだったんだっけな？

@ueda

お互いに協力しているようで、実は丸投げしている（されている）

権限を伴って責任を引き受けるような場面にあまり遭遇していない？

そういう土壌があるところじゃないと難しい。あるいは培っていけるような環境。

割り振られる、というか、押し付けられる経験しかない 共感できる(@kobatomo)

@kobatomo

負荷の高い人の仕事を受け取る時も、これやってますね。自分で見積もって、関係者とインセプションデッキ作って、共有。これを最初にしないとコミュニケーションに失敗したことがある。

最近押し付けられる ゴールを明確にするのが大事だと学んだ(@kobatomo)

@got4416

責任が無いと他人事になることが多い経験。

他人事ではなく自分事とするための、自分（自分たち）への規律に感じる。

今日のふりかえり

議事録書きながらやったのは良かった(@kkd)

時間配分が反省(@kkd)

サザエさんよかった(@ueda)

文字と音声で頭に入ってきやすかった(@ueda)

人間性と自己相似性がいまきてる(@kobatomo)

先に課題書き出すのはよかった(@got4416)

言いたいことが出てきたのでまとめきれてない(@got4416)

HackMDリアルタイムすごいな！(@got4416)

次回

1/10 19:30-

５章結論から７章ペアプロまで

司会：小林

Connpass:got

Wiki:ueda

12/28 は忘年会